The present invention relates to generally computer systems, and particularly to computer database management systems.
As computing becomes ever more pervasive in modern society, the importance of databases, and tools for managing databases, continues to increase. Once used merely to store large amounts of data, modern databases now form the backbone of many, if not most, sophisticated enterprise applications. Merely by way of example, enterprise-class database systems, such as Oracle Corp.'s Oracle 10 g™ relational database management system (“RDBMS”), provide the back-end for virtually all enterprise resource planning (“ERP”) and customer relationship management (“CRM”) software applications, as well as many e-commerce applications, Internet web sites and the like.
As the applications for databases have expanded, so have the methods and tools for interacting with those databases. In the past, a proprietary client application would be used to open a dedicated “session” with an RDBMS (and/or an instance thereof) to interact with the database. Through this dedicated session, the client application could access, modify and/or add to data in the database. It was not always easy, however, to identify the client or its such interactions with the database. In some cases, such arrangements provided the ability to trace structured query language (“SQL”) requests made during a particular session, measure the resources consumed by a particular session, etc. First, however, the session generally needed to be identified from all others.
Now, however, a variety of different methods are used to interact with a database. Merely by way of example, a database user might interact with a database (and/or an associated RDBMS) via a web browser instead of with a client application. In other circumstances, a database might be used to power a business application. In such cases, the end user may never interact with the database itself, but instead might make requests of the business application (through a dedicated client of the business application, a web browser, etc.), which might cause the business application to interact with the database.
Now, in order to provide enhanced scalability, responsiveness and/or reliability, many companies choose to operate databases in a clustered environment. In such an environment (and in other cases as well), the RDBMS might be configured to provide “connection pooling,” where each client transaction (whether from a business application or directly from an end user) may be managed by the cluster and allocated to an appropriate node and/or instance of the database and/or server (depending, for example, on relative transaction costs, relative loads on each node at the time of the transaction, etc.). Under these circumstances, therefore two transactions with the same client might be handled by two different nodes/instances. Such concepts have been in use on mainframes for some time and are now gaining popularity in clustered database environments.
While these advanced modes of interaction with databases unquestionably provide many benefits unavailable in the dedicated client-server architecture, they also increase the difficulty of managing the relationship between the database and its clients or users. Merely by way of example, if a user accesses a database through a web browser instead of a dedicated client, it may be difficult to implement the concept of a persistent “session,” since each transaction between the web browser and the database essentially opens a new session and/or uses one of a pool of open sessions. Moreover, if an end user uses a database only through a business application, it may be difficult for a database administrator to determine which transactions between the database and the business application relate to that user's interaction with the business application, which can, for example, make it problematic to troubleshoot any persistent problems (such as performance issues, etc.) experienced by that user. The same circumstances make it difficult to trace transactions associated with a particular client or business function from a business application or to collect any meaningful statistics about such transactions.
It would be useful, therefore, to provide a way for an RDBMS (and/or an administrator) to identify transactions in a more sophisticated manner.